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1  Technical  Requirements 


1.1  Extend  SIMNET  Network  and  Protocols 


The  extension  of  the  SIMNET  protocols  to  meet  the  requirements  of  the  air  combat 
appUcation  has  progressed  in  two  areas.  The  informal  area  involved  concept  dewlopment 
and  rapid  prototyping  to  determine  where  the  protocol  needed  to  be  enhanced,  ^e 
formalizition  of  these  enhancements  via  the  Distributed  Interactive  Simulation  (DIS) 
standards  process. 


1.1.1  RAPID  Prototype 

The  rapid  prototype  for  the  protocol  extension  was  demonstrated  at  the  - 

Interse^ice/Industry  Training  Systems  Conference  (ITTSC)  in  Ft.  Worth  Texas,  November 
13-16, 1989.  Work  on  the  rapid  prototype  began  with  informal  meetings  between 
representatives  of  McDonnell  Douglas  Aircrait  Company  and  BBN  on  23  May  1989,  three 
months  in  advance  of  the  MULTIFC^D  project  funding. 


The  purpose  of  the  rapid  prototype  was  to  integrate  a  high  fidelity  aircraft  simulator  onto 
the  SIMNET  network  and  demonstrate  the  feasibility  of  using  the  SIMNET  protocol  to 
interface  aircraft  simulators  over  an  Ethernet.  Appendix  A  contains  the  summary  of  the 
task  that  was  delivered  to  HRL  in  Decembe''  1989. 


The  rapid  protype  task  pointed  out  that  fighter  aircraft  could  indeed  engage  using  the 
SIMNET  protocol,  however  the  protocol  was  not  robust  in  the  support  of  electronic 
countermeasures  and  the  specification  of  aircraft  weapons  and  self  defense  systems.  This 
observation  was  confirmed  at  a  technical  interchange  meeting  at  McDonneU  Douglas 
Aircraft  on  xx  where  a  Tactical  Air  Command  simulator  training  exercise  was  observed. 


1 


BBN  Systems  and  Technologies 


Report  No.  7621 


1.1.2  DIS  Participation 

The  MULTIRAD  program  has  provided  support  to  the  DIS  standardization  process.  This 
support  included  participation  in  general  and  working  group  sessions.  The  DIS  process 
participation  included  attendance  by  BBN  personnel  representing  MULTIRAD  interests  at 
the  symposiums  on: 


15  January  1990 
6  August  1990 
January  1991 


At  the  6  August  1990  sympopsium,  a  proposal  was  made  by  BBN  as  a  representative  of 
MULTIRAD.  A  presentation  of  the  proposed  Radar  Emitter  PDU  are  presented  in 
Appendix  B. 

1.2  Procure,  Extend,  Install,  Test  Systems 

1.2.1  NIUs 

The  Network  Interface  Unit  (NIU)  was  developed  from  the  specification  in  the  customer 
Statement  of  Work  and  the  prototype  effort  undertaken  in  the  fall  of  1989  that  culminated 
in  the  rapid  prototype  effort  for  IITSC  1989.  The  philosophy  that  motivated  the  NIU  was 
to  develop  a" service  that  would  easily  integrate  existing  simulators,  that  were  created  as 
stand  alone  devices,  with  the  SIMNET  network.  Since  the  software  base  to  be 

used  for  the  NIU  was  60%  extracted  directly  for  the  existing  body  of  the  SIMNET  vehicle 
simulatio  iftware,  the  critical  element  was  to  agree  on  a  interface  protocol  between  the 
NIU  and  the  f  evice  that  it  was  to  attach  to  the  network. 


The  NIU  approach  was  reviewed  at  the  following  technical  interchange  meetings: 

System  Requirements  Review  19  December  1989 

Preliminary  Design  Review  '  19  March  1990 

Critical  Design  Review  10  December  1990 


The  NIU/Host  interface  was  developed  in  two  stages: 


1)  A  generic  interface  for  proof-of-principle  testing. 


2)  A  device  specific  interface  for  each  device  integrated  onto 
the  network  via  the  NIU. 
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The  generic  interface  was  designed  and  documented  in  a  preliminary  specification  delivered 
9  February  1990.  It  was  revised  in  a  supplementary  release  6  June  1990. 

The  NIU  software  development  using  the  generic  host  interface  proceeded  from  the 
preliminary  design  review  until  release  to  BBN  Phoenix,  19  July  1990.  Thus  ending  the 
first  stage. 


Specific  device  interfaces  were  developed  and  demonstrated  on  the  following  dates: 


Cockpit  Engagement  Trainer 
Ground  Control  Intercept  Station 
McDonnell  Douglas  Reconfigurable 
Cockpit 


7  September  1990 
28  September  1990 

3  November  1990 


This  second  stage  has  been  an  ongoing  activity  with  gradual  expansion  of  the  capability  of 
each  system  to  interact  across  the  network. 


The  development  of  the  NIU  did  not  follow  rigorous  software  development  practices.  In  as 
much  as  it  leveraged  the  use  of  existing  proven  software,  as  opposed  to  existing, 
rigorously  developed  and  tested  software,  it  was  a  low  risk  venture. 


The  concept  of  a  Network  Interface  service  as  a  seperate  logical  entity  is  a  good  one.  A 
common  collection  of  services  that  any  device  may  use  to  interface  onto  a  network  running 
a  standardized  protocol,  should  be  identically  implemented  on  each  device  an  hence  insure 
the  compatibility  of  the  systems  across  the  network.  Embodying  these  services  in  a 
seperate  piece  of  hardware,  the  NIU,  has  proven  to  be  a  less  than  optimal  design.  It  has 
induced  the  creation  of  many  custom  interfaces  to  the  network  service,  where  a  generic 
library  of  functions  would  have  been  adequate.  The  maintenance  of  these  custom  interfaces 
becomes  a  cumbersome  configuration  task  which  will  inevidably  inhibit  the  system  from 
taking  full  advantage  of  a  distributed  environment. 


1.2.2  Operations  and  Maintenance  Station  /  NOM 

The  SIMNET  Network  Operations  and  Maintenance  (NOM)  module  was  selected  to  fulfill 
the  requirement  for  the  Operations  and  Maintenance  Station.  The  SIMNET  NOM  provides 
limited  power-up  and  -down  capabilities,  file  transfer  functions,  and  permits  the  network 
operator/maintainer  to  monitor  the  status  of  devices  on  thet  netwoik.  The  NOM  performs 
this  monitoring  function  by  listening  for  regular  (e.g.,  appear^ce)  PDUs  from  simulators 
and  by  listening  for  specific  PDUs  in  which  simulator  status  is  recorded,  for  example, 
over-temperature  condition  or  that  a  simulator  is  in  emergency  shutdown.  It  was  agreed  by 
all  concerned  that  with  some  minimal  effort,  the  NOM  would  fulfill  the  lab's  needs. 
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At  the  time  that  this  selection  was  made,  the  SIMNET  NOM  ran  on  a  Masscomp  5600 
computer;  however,  plans  were  afoot  to  port  the  NOM  to  a  Masscomp  6600  computer.  So 
that  the  MULTIRAD  NOM  would  be  compatible  with  the  new  SIMNET  NOM,  a 
Masscomp  6600  computer  and  associated  peripherals  were  purchased  and  delivered  to 
Williams  AFB.  Subsequently,  the  DARPA  SIMNET  Program  Management  Office  decided 
not  to  port  the  SIMNET  NOM  to  the  new  hardware  platform.  It  was  decided  that  the 
MULTIRAD  project  would  not  pay  to  have  the  SIMNET  NOM  ported  to  the  new 
hardware. 


At  the  conclusion  of  the  contract,  the  Masscomp  6600  and  associated  peripherals  were  on¬ 
site  at  Williams  AFB.  As  part  of  the  SIMNET  project,  "cold-start"  materials  for  the  NOM 
were  created  which  contain  all  source  code  for  the  NOM  and  instructions  on  how  to 
compile,  link  and  load  the  software.  A  copy  of  these  materials  was  provided  to  WAFB. 


1.2.3  Long  Haul  Network  (LHN)  Gateway 

The  LHN  gateway  is  a  processor  and  application  that  serves  to  link  Local  Area  Networks 
(LANs).  The  technical  challenge  is  to  seamlessly  join  LANs  that  are  operating  at  a  relatively 
high  bandwidth  (up  to  10  megabits/sec  for  ethemet)  via  long  distance  communication 
channels,  such  as  telephone  lines,  which  are  of  much  lower  bandwidth.  Seamless  implies 
that  interactions  between  simulators  across  the  LHN  is  no  different  from  interactions 
between  devices  that  are  on  the  local  network. 


The  LHN  gateway  requirements  are  outlined  in  the  customer  SOW.  It  was  determined  at 
the  technical  interchange  meeting  in  February  1990  that  the  procurement  of  a  LHN  gateway 
and  development  related  to  the  LHN  gateway  was  beyond  the  scope  of  work  for  this  phase 
of  the  program.  New  developments  in  Wide  Area  Network  technology,  packet  switch 
development,  and  implementation  of  the  ST  Protocol  made  the  investment  in  current 
technology  less  appealing.  The  requirement  to  deliver  and  document  such  a  system  was 
therefor  dropped. 


A  proof  of  principle  demonstration  to  verify  that  simulators  integrated  onto  the  network  at 
HRL  were  indeed  SIMNET  compatible  and  could  interoperate  over  a  LHN  was  organized 
in  conjunction  with  other  HTSC  demonstrations  November  3-5,  1990.  A  synopsis  of  this 
activity  is  presented  in  appendix  C. 
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The  LHN  Gateway  that  was  installed  at  AFHRL  was  assembled  in  part  from  hardware 
loaned  to  the  demonstration  by  BBN.  Specific  parts  of  the  gateway  were  available  only  for 
support  of  the  demonstration  and  were  returned  to  BBN  after  the  demonstration  completed. 
The  items  returned  to  BBN  are: 


-  2  Butterfly  Interface  Modules  (BIO) 

- 1  CMC  Ethernet  Controller  (ENP-30) 


To  operate  the  gateway  for  it’s  intended  purpose,  thes  items  would  need  to  be  aquired.  In 
addition,  the  gateway  has  a  wide  variety  of  user  interface  tools  that  would  need  to  be 
supported.  These  tools  use  an  Apple  computer  as  the  host.. 


1.2.4  Digi..^j  Voice 

Initial  design  began  with  a  meeting  involving  Alan  Oatman  and  Steve  McGarry  8  December 
1989.  Among  the  issues  was  the  division  of  labor  between  BBN  and  GE.  It  was  initially 
decided  that  GE  would  likely  handle  the  cockpit  interface  (DED  and  heads-up  display)  and 
analog  circuitry  (matching  the  SIMVAD's  levels  to  the  pilots  headset).  The  sof^'^  was 
largely  to  be  a  port  of  the  Masscomp-based  applicaition  that  had  been  done  for  CECOM, 
with  changes  mainly  in  the  controls  interface,  which  now  had  to  go  through  the  NIU.  First 
customer  meeting  occured  13  December  1989  at  Williams  AFB.  WAyne  MaKhall 
promised  info  on  F-16  commo  gear,  which  Alan  delivered  8  Janua^  1990.  CLient  pointed 
me  to  ESD  at  Hanscom,  which  pointed  me  to  Jim  Bradford  at  MITRE.  Met  with  him  on  22 
February  1990,  at  which  time  he  gave  me  an  overview  of  HAVE  QUICK,  the  UW  system 
installed  in  the  F-16  as  an  extension  to  ARC- 164.  The  CECOM  simulation  was  for  VHF, 

implying  changes  to  the  propagation  model  (a  simplification , actually).  The  only 

information  I  couldn't  get  was  on  the  hop  rate.  This  was  becuase  my  clearance  hadn  t  been 
sent  to  MITRE  in  time. 

Second  briefing  19-20  March  1990  at  Williams  Presented  proposal  for  voice  component. 
Began  gatherin  headset  info  from  David  Clark,  starting  5  April  1990.  At  this  point,  plan 
was  to  implement  a  standalone  interface  for  demo  purposes,  using  low-impedance  (MIL- 
SPEC)  to  allow  use  with  pilot  headsets.  At  this  point,  Dave  WHittemore  gathering  parts 
and  information  to  design  analog  interface  between  her  list  sandSIMVAD.  This  headset 
adapter  was  tested  19  September  1990  by  Paul  Metzger  with  an  Army  aviauon  headset,  and 
worked.  Headsets  from  David  Clark  arrived  20  April  1990.  Dave  had  amp  pretty  far  aJong 
by  5  June,  deciding  to  go  for  non-battery  power  that  day,  opting  for  VME  draw  instead. 

The  M VME- 147  board  was  chosen  as  the  CPU,  becuase  BBN  had  system  software  for  it, 
and  the  NIU  was  also  using  it. 

Code  conversion  began  in  earnest  week  of  9  July.  Installed  19-21  September.  System  is 
working,  although  an  alleged  packet  duplication  buyg  remains  due.  to  lack  of  funding  for 

repair. 

Number  one  goal  for  future  work  is  completion  of  the  cockpit  interface.  GE  must  be 
clearly  assigned  task  of  getting  controls  completed  and  interface  to  NIU  working.  BBN 
must  do  NIU-to- Voice  host  interface  and  controls  integration. 
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1.2.5  MCC  System 

Due  to  budgetary  and  utility  constraints,  it  was  decided  that  no  SIMNET  MCC  system 
would  be  delivered  as  part  of  the  MULTIRAD  network. 


1.2.6  Message  CoIIeci  '  Data  Analysis 

All  traffic  on  the  MULTIRAD  network  may  be  collected  on  the  SIMNET  DataLogger 
which  is  installed  on  the  network  at  WAFB.  The  DataLogger  records  all  network  traffic- 
including  vehicle  appearance  PDUs,  radar  PDUs  and  all  others— onto  a  file  on  disk.  The 
recorded  data  may  be  played  back  onto  the  network  for  subsequent  review,  or  the  file  may 
be  transfered  to  a  9-track  magnetic  tape  for  off-line  analysis. 


Due  to  budgetary  constraints,  no  further  SIMNET  Data  Analysis  equipment  was  purchased 
for  the  MULTIRAD  network. 


1.3  Optional  LANs 

The  original  MULTIRAD  SOW  called  for  installation  of  LANs  at  several  sites  other  than 
WAFB,  including  VTRS  in  Orlando,  FL,  SIMNET  Research  Center  at  Orlando  AFB, 
SCTR  at  Ft.  Rucker,  AL,  and  CCTR  at  Wright-Patterson  AFB,  OH.  No  such  installations 
were  ever  approved  or  authorized. 
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2  Specifications 

2.1  ACME  Network  Interface  and  Protocol  Specification 

One  of  the  stated  design  goals  of  MULTIRAD  was  that  SIMNET  protocols  be  used 
wherever  possible.  The  NIU  uses  an  extended  version  of  the  SIMNET  version  6.6. 
protocols  to  pass  vehicle  appearance  and  other  information  over  the  MULTIRAD  network. 
Where  necessary,  extensions  have  been  added  to  pass  information,  e.g.,  radar  emission 
information  which  is  required  for  certain  aircraft  simulations,  but  which  could  not  be 
represented  in  the  basic  SIMNET  6.6  protocol.  A  full  description  of  the  SIMNET  protocol 
may  be  found  in  BBN  Report  #7102,  "The  SIMNET  Protocol"  and  the  addendum 
document  which  describes  the  protocol  changes  between  SIMNET  6.0  and  SIMNET  6.6. 
A  detailed  listing  of  the  protocol  in  use  at  WAFB  may  be  found  in  the  NIU  Detailed  Design 
Specification.  [Jon  Doran -is  this  correct?] 


Also,  BBN  personnel  created  a  "MULTIRAD  Network  Design  Specification  which 
includes  all  details  of  how  the  network  is  constructed.  This  includes  a  descnpoon  of  the 
physical  and  logical  layout  of  the  network,  and  instmctions  for  operation  of  all  elements  of 
the  network. 


2.2  Three  Subsystems 


2.2.1  Network  Interface  Node  (NIU) 

BBN  personnel  at  WiUiams  Air  Force  Base  produced  a  document  entitl<;d  "Network 
Interface  Unit  Detailed  Design  Specification."  This  document  describes  the  NIU  in 
complete  and  exacting  detail.  Included  are  sections  on  NIU  overview,  hardware  and 
software  architecture,  and  detailed  information  about  each  of  the  software  modules  and 
libraries.  All  parties  interested  in  understanding  the  workings  of  the  NIU  should  refer  to 
this  document. 


2.2.2  Digitized  Voice  Communications 

What  we  delivered  was  a  basic  voice  interface  which  communicated  over  the  simulation 
network.  Tuning  can  only  be  done  from  the  simulator  s  keyboard,  since  the  cockpit 
interface  was  never  done. 

The  customer's  statement  of  work  was  ambitious  for  the  available  money.  There  as 
constant  confusion  over  the  responsiblities  of  the  various  contractors,  with  the  client 
changing  assignments  constantly.  Most  notable  were  the  cockpit  interface,  which  GE 
never  built,  and  the  tones  generator,  resposibility  for  which  shuttled  between  BBN  and  UE 
monthly.  After  the  initial  demonstration  was  completed,  demand  for  features  that  had 
earlier  been  dropped,  such  as  instructor's  interface,  resurfaced.  We  ran  out  of  time  and  out 
of  money. 
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2.2.3  Gateway 

The  requirement  for  delivery  of  a  LHN  Gateway  specification  was  deferred.  This  occured 
at  the  intercahnge  meeting  of  12  July  1990.  The  decision  to  defer  after  determining  that 
LHN  capability  was  a  secondary  development  pnority  and  the  technology  for  Wide  Area 
NetworWng  of  simulators  was  in  transition. 
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3  Engineering  Interface  Support 

BBN  personnel  at  Williams  AFB  presented  technical  papers  at--and  otherwise  participated 
in— several  technical  interchanges,  including  the  I/TTSC  shows  in  1990  and  1991  and  in 
several  conferences  at  which  the  SIMNET  protocols  were  discussed. 


Throughout  the  contract  period,  perhaps  the  largest  single  effort  for  BBN  personnel  at 
Williams  AFB  was  providing  day-to-day  support  of  the  Williams  AFB  MULTIRAD 
network.  This  included  support  for  many  demonstrations  of  the  NIU  ^d  the  network, 
participation,  in  meetings  with  government  and  contractor  agencies  to  discuss  operation  of 
the  network,  answering  questions  from  -'"♦side  parties  about  the  MULTIRAD  network, 
etc.  BBN  personnel  created  a  documer.  'led  "Network  OperaLans  Procedures;"  this 
document  is  to  be  used  as  an  aid  to  non-  liN  yerroi-nei  r'  start  tfit  computers  and  run  the 
network.  A  copy  of  this  document  is  attached 


BBN  personnel  in  Cambridge  performed  a  study  on  the  use  of  "dead  reckoning  in  the 
SIMNET  protocols.  AF/H^  provided  data  (in  the  form  of  data  from  the  flight  of  a  flight 
simulator)  and  initial  funding  for  this  study.  When  funding  for  the  MULTIRAD  project 
became  criticial,  it  was  decided  that  the  dead-reckoning  study  should  be  discontinued. 

BBN  continued  this  study  at  its  own  expense,  and  presented  the  results  of  the  study  at  the 
Fourth  Workshop  on  Standards  for  the  Interoperability  of  Defense  Sirnulations  in  Orlando, 
FL,  13-15  March  1991.  A  copy  of  this  White  Paper  is  appended  to  this  document. 


3.1  Participate  in  and  Present  at  Technical  Interchanges 
Technical  Interchanges  for  this  project  assumed  four  forms: 

-  Formal  Design  Reviews  of  Project  Systems 

-  Representation  of  the  project  at  Symposiums  and  Conferences 

of  the  Simulation  Community 

-  Technical  Conferences  with  Subject  Matter  Exp?ns  and 

Inaustry  Participants 

-  Informal  Status  and  Direction  Sessions 


3.1.1  Formal  Design  Reviews 
The  formal  sessions  for  the  project  were: 

19  December  1989 
19  March  1990 
10  December  1990 


System  Requirements  Review 
Preliminary  design  Review 
Critical  Design  Review 
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The  System  Requirements  Review  was  a  BBN  internal  peer  review  where  the  systems, 
primarily  the  NIU,  was  discussed  relative  to  the  SOW  requirements,  implied  requirements, 
and  derived  requirements  that  specified  its  design.  The  purpose  of  this  review  was  to 
demonsLate  that  the  development  philosophy  of  the  NIU  was  consistent  with  the 
distributed  simulation  methodology. 


s 

I 

I 

I 


The  Preliminary  Design  Review  was  held  to  inform  the  HRL  user  community  of  the^ 
program  progress  and  to  revp  m  the  proposed  interfaces  to  the  existing  (and  developing) 
devices  at  the  laboratory.  It  is  accepted  that  the  level  of  detail  of  the  presentations  at  the 
PDR  was  not  fine  enough  in  all  areas. 


The  Critical  Design  Review  of  10  December  was  not  a  well  received  nor  particularly  well 
prepar^  event.  It  was  generally  viewed  as  unacceptible  in  most  areas.  Following  the  CDR, 
the  program  was  re-focused  and  key  individuals  were  replaced.  The  program  goals  were 
focused  on  the  documentation  of  the  project  efforts  and  development  was  curtailed. 


3.1.2  Symposia  and  Conferences 

Project  personnel  participated  in  two  major  simulation  conference  activities;  the  DIS 
Protocol  Standardization  effort  and  the  annual  IITSC  event.  Over  the  course  of  the  program 
the  following  events  were  attended; 


DIS  Conference 

15  January  1990 

29  March  1990 

(Working  Group) 

19  July  1990 

7  August  1990 

(Working  Group) 

IITSC 

13  November  1989 

3  November  1990 
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3.1.3  Technical  Conferences  with  Industry  Participants 

Because  distributed  simulation  is  being  introduced  to  the  avdation  community  via  the 
MULTIRAD  program,  numerous  conferences  were  held  with  industry  leaders  in  aircraft 
production  and  simulation.  Primarily  these  interchanges  enabled  the  exposure  of  distributed 
simulation  applications  to  the  peer  review  of  knowledgable  simulation  departments  in 
aircraft  manufacturing  facilities.  These  interchanges  were  held: 


McDonnell  Douglas 


23  May  1989 
28  August  1989 
12  April  1990 


General  Dynamics  20  April  1990 

28  July  1990 
20  August  1990 

In  each  meeting,  distributed  simulation  protocol  issues,  such  as  reflected  in  the  Radar  PDU 
development,  were  reviewed  and  critiqued. 


3.1.4  Informal  Interchanges 

Informal  interchanges  were  held  frequendy  after  BBN  representidves  were  established  on 
site.  The  interchanges  were  held  at  least  twice  monthly  for  the  duration  of  the  project  at 
WAFB.  Significant  meetings  were  held  at  BBN  Cambridge  on  3  May  and  12  July  1990. 


3.2  Analyze  Potential  Network  Interface  Designs 

Network  media  other  than  Ethernet  were  researched  under  the  MULTIRAD  program.  The 
media  explored  was  the  use  of  the  Fiber  Distributed  Data  Interface  (FDDI).  An  FDE)!  white 
paper  was  developed  and  released  on  9  January  1990.  This  paper  was  primarily  an  industry 
survey  that  investigated  the  state-of-the-art  in  FDDI  controllers  and  the  standardization 
process  of  FDDI.  The  conclusions  of  the  investigation  were  that  intelligent  controllers  were 
teing  developed  that  offered  an  attractive  alternative  to  the  controllers  available  in  January 
1990.  These  would  be  more  suitable  to  the  intended  purpose  -  integration  into  the  NIU. 

A  second  study  was  provided  on  27  June  1990  that  outlined  a  plan  to  integrate  the  FDDI 
controllers  into  the  NRJ. 

Investigation  of  FDDI  was  terminated  following  the  10  December  CDR. 
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3.3  Evaluate  Compliance  of  Designs  to  Network 

The  network  protocol  compliance  of  the  systems  developed  under  the  MULTIRAD 
program  have  been  proven  by  demonstration.  The  interoperability  of  the  new  systems  with 
existing  SIMNET  systems  continues  to  be  demonstrated  with  the  operation  of  the  PVD  and 
the  Logger  on  the  MULTIRAD  network. 

No  explicit  tests  were  run  on  the  systems  to  verify  compliance. 


3.4  Support  Integration  Testing 

The  primary  role  of  BBN  on  site  personnel  through  December  of  1990  was  the  integration 
support  of  the  CET,  GCI,  MDRC,  and  AIT  onto  the  network. 


B 

B 
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APPENDIX  A:  I/ITSC  RAPID  PROTOTYPE  TASK  SUMMARY 
I/ITSC  Lessons  Learned 
22  November  89 

Stephen  M.  McGarry 

BBN  Systems  and  Technologies  Corporation 
Advanced  Simulation  Division 

The  goals  of  the  rapid  prototype  project  were: 

to  demonstrate  the  netv^orking  of  a  device  not  built  exclusively  by  the  SIMNET 
contractors. 

to  discover  what  challenges  await  those  planning  to  incorporate  existing  devices  on 
SIMNET. 


In  the  course  of  integrating  the  SIMNET  protocol  into  the  McEionnell  Douglas  devices 
several  discoveries  were  made  that  bear  review  by  any  groups  interested  in  porting  the 
SIMNET  Protocol  to  existing  devices.  These  observation''  are  intended  to  highlight  areas 
of  possible  consternation  and  help  to  ease  the  transition. 


CONFIGURATION:  The  system  was  initially  conceived  as  three  MCAIR  devices: 


F-15  manned  cockpit 
F- 1 8  manned  cockpit 
Digital  Threat  Unit 


These  three  devices  are  of  common  computer  architecture  and  were  to  be  linked  to  allow 
interaction  in  an  air-to-air  scenario  using  the  SIMNET  protocols.  This  configuration  would 
allow  for  8  vehicles  (2  manned,  6  digital)  to  be  on  the  network. 
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Because  each  system  subscribed  to  a  common  communication  metliod,  the  SIMNET 
protocol  standard,  the  rapid  prototype  demo  evolved  into  a  much  more  robust 
demonstration  than  originally  envisioned.  The  commonality  ^  f  communication  standard 
with  existing  SIMNET  devices  allowed  for  the  interaction  with: 


the  SIMNET  observation  vehicle 
the  SIMNET  Plan  View  Display 
the  SIMNET  Data  Logger 

The  SIMNET  Semi-automated  Forces  via  long  haul  link  to  Cambridge,  MA. 


Linking  with  these  pre-existing  SIMNET  devices  substantiates  the  use  of  the  SIMNET 
protocol  and  emphasized  the  benefits  of  network  compatibility  by  having  these  pre-existing 
SIMNET  devices  provide: 


GCI  support 

Air  Defense  Vehicles 

Network  wide  record/replay 

force  multipliers  via  Semi-Automated  Forces 


all  of  which  were  demonstrated  on  the  show  floor. 


EXERCISE  IDs:  The  Ethernet  Network  at  the  I/ITSC  show  was  being  shared  by  several 
different  exercises  ranging  in  size  from  8  vehicles  (rapid  prototype)  to  several  hundred 
(BBN  Semi  Automated  Forces  Demonstration  and  Ixigged  Exercise  Demonstration). 
These  exercises  ran  simultaneously  without  interference  using  an  exercise  ED  contained  in 
the  PDU  header  as  a  discriminator. 


It  was  noted  that  the  Plan  View  Display  (which  can  observe  all  exercises  simultaneously, 
or  one  exercise  only)  displayed  inadvertent  force  alignment  shifts  of  the  rapid  prototype 
vehicles  during  replay  of  a  logged  exercise.  This  is  attributed  to  conflicting  vehicle  IDs 
between  the  rapid  prototype  and  the  logged  exercise.  This  anomaly  is  purely  the  outgrowth 
of  having  an  omniscient  device  (the  PVD)  observing  on  the  network,  a  tactical  device 
within  an  exercise  adhering  to  normal  protocol  practices  would  have  no  such  difficulty. 


UNITS:  It  cannot  be  overstressed  that  the  units  of  measure  in  the  SIMNET  protocol  are 
metric  and  those  of  most  existing  aircraft  simulators  are  not.  Since  unit  conversions  can  be 
handled  in  a  trivial  manner,  typically  with  a  multiply,  this  is  not  an  issue  that  requires 
extensive  engineering  creativity  to  solve.  It  does,  however,  require  dogged  persistence  to 
insure  that  the  units  are  always  accounted  for. 
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The  impact  on  thruput  is  a  function  of  the  relative  capacity  of  the  system.  Microprocessor 
based  appUcations  with  limited  floating  point  support  will  tend  to  pay  a  more  severe  penalty 
than  larger  hosts.  This  will  be  moit  significant  in  larger  exercises  than  in  smaller  ones.  A 
single  vehicle  simulator  will  have  to  allocate  more  CPU  time  processing  received  PDUs 
than  transmitted  PDUs  in  a  multiple  vehicle  exercise. 


COORDINATE  SYSTEMS:  Since  the  vehicle  rotation  matrix  is  a  part  of  the  vehicle 
appearance  packet  the  transformation  between  an  arbitrary  frame  of  reference  into  and  out 
of  the  SIMNET  frame  of  reference  is  a  potentially  costly  one.  In  a  multiple  vehicle  exercise 
this  transformation  must  be  applied  to  each  appearance  packet  received  and  transmitted, 
with  the  receive  case  typically  the  more  demanding. 


For  the  rapid  prototype  a  heuristically  derived  mapping  scheme  was  utilized  that 
transformed  the  North-East-Down  (NED)  coordinate  system  into  and  out  of  the  SmNbl 
system  and  considerably  reduced  the  thruput  required  to  perform  the  three  dimensional 
rotations.  In  general,  this  issue  is  best  addressed  by  starting  the  simulation  in  the  coordinate 
system  expected  by  the  network  rather  than  converti  ng  at  the  interface. 


STATUS  FLAG  CONVERSION:  Existing  simulations  naturally  have  mechanized  methods 
for  noting  significant  status  changes  and  recording  them  for  the  operator  (i.e.  the  fire  ball 
for  what  used  to  be  a  target).  The  event  conversions,  which  are  piotentially  burdensome, 
were  mapped  from  the  SIMNET  definitions  into  agreed  status  flags  for  the  host  system. 


PROTOCOL  OVERHEAD:  For  the  rapid  prototype  system  the  majority  of  the  overhe^ 
associated  with  converting  to  the  SIMNET  protocol  at  the  interface  was  in  the  areas  of: 


conversion  of  units 
rotation  of  coordinate  systems 
conversion  of  status  flags 
dead  reckoning  of  vehicles 


The  observed  CPU  loading  on  the  68030  based  microprocessor  was  <=  2.25ms  per  vehicle 
at  any  time  during  the  demonstration. 


ETHERNET  BANDWIDTH:  The  exercise  that  was  established  involved  8  tactical  vehicl 
es,  two  of  which  were  manned.  The  first  order  dead  reckoning  model  as  described  in  the 
SIMNET  Protocol  Description  Document  was  used  to  reduce  the  Ethernet  bandwidth. 


15 


BBN  Systems  and  Technologies 


Report  No.  7621 


The  discrepancy  thresholds  for  the  air  vehicles  were  set  to  5%  of  the  vehicle  dimension  in 
each  axis  for  location,  and  1  degree  of  rotation  about  each  local  axis.  Since  the  vehicle 
were  operating  at  20HZ,  the  maximum  appearance  packet  generation  was  20  packets  per 
second  (pps)  and  could  be  generated  by  a  ra  pidly  maneuvering  vehicle.  The  observed 
nominal  packet  rate  was  approximately  8pps  per  vehicle.  Even  with  the  reduce  packet  rate 
pilots  were  flying  formation  and  tracking  targets  without  difficulty  or  objections. 


DIFFERING  FRAME  RATES:  The  MCAIR  vehicles  ran  at  a  20Hz  frame  rate  while  the 
BBN  devices  operated  at  15Hz.  The  skew  in  the  frame  rates  combined  with  the  dead 
reckoning  model  caused  an  anomaly  observed  in  the  BBN  observation  vehicle,  though  not 
in  the  MCAIR  devices.  This  anomaly  manifested  itself  as  target  jitter  on  the  Observation 
Vehicle  visual  display. 


An  algorithm  for  smoothing  this  jitter  was  employed  on  the  Observation  Vehicle  which 
eliminated  all  jitter  when  utilized. 


PROTOCOL  USAGE:  Expediency  dictated  that  the  full  SIMNET  protocol  not  be 
implemented  in  the  rapid  prototype.  Only  the  minimal  subset  of  elements  required  to 
accomplish  a  suitable  exercise  were  utilized.  These  elements  were  exclusively  elements  of 
the  Simulation  Protocol,  as  opposed  to  the  Data  Collection  protocol.  The  PDU's  that  were 
implemented  were: 


-  Activating 

-  Appearance 

-  Fire 

-  Impact 

-  Deactivate 


These  were  found  to  be  sufficient  to  accomplish  the  exercise  objectives. 


INITIAL  CONDITIONS:  The  reset  state  for  aiicraft  simulations  tends  to  require  special 
coordination  between  the  aero  models  and  the  visual  system.  Likewise,  it  requires 
consideration  for  the  visual  systems  of  others  on  the  network,  and  for  network  bandwidth 
in  general. 


To  achieve  proper  trim,  the  aero  model  requires  some  velocity,  trim  velocity,  which  will  fix 
the  aircraft  attitude.  In  a  reset  or  freeze  state,  however,  the  position  of  the  vehicle  is  not 
updated  when  passed  to  the  visual  system.  The  artifice  of  an  unmoving  vehicle  that  has  a 
velocity  causes  other  vehicles  on  the  network  to  dead  reckon  the  vehicle  away  from  the 
freeze  position,  only  to  be  called  back  by  an  appearance  update  when  the  thresholds  are 
exceeded.  This  cycle  of  continually  repositioning  a  frozen  vehicle  appears  as  jitter  in  other 
systems  on  the  network. 
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To  alleviate  this  potential  difficulty  it  is  recommended  that  a  velocity  of  0  be  placed  on  the 
network  when  the  vehicle  is  in  a  reset  or  freeze  state. 

DATABASE  CORRELATION:  The  MCAIR  simulators  used  a  different  database  from  the 
SIMNET  devices  which  resulted  in  several  accommodations. 

To  enable  the  representation  of  aircraft  on  the  ground  in  both  systems,  the  position  of  Ae 
runway  was  established  and  used  as  an  offset  constant.  This  position  vector  was  applied 
and  removed  by  the  MCAIR  devices  at  the  interface. 


In  order  to  obtain  a  horizon  reference  in  the  Observation  Vehicle  visual  system  the  altitude 
of  the  exercise  was  brought  down  to  3000  ft.  This  is  a  low  altitude  for  air  combat 
maneuvering  exercises. 

These  compromises  were  sufficient  for  obtaining  the  exercise  obj-xtives  but  could  have 
been  eliminated  by  using  compatible  databases. 

LONG  HAUL;  Ground  targets  were  added  to  the  exercise  via  the  semi  automated  forces 
system  located  in  Cambridge,  MA.  These  were  air  defense  vehicles  armed  with  surface  to 
air  missiles.  This  long  haul  addition  provided  a  new  dimension  to  the  exercise,  allowing 
air-to-ground  strikes  by  the  manned  simulators  against  a  competent  adversary.  The 
diversity  was  found  to  be  a  significant  tactical  and  technical  achievement. 
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APPENDIX  B:  RADAR  PDU  DEVELOPMENT 
RADAR  PDU  HISTORY 

For  the  AFHRL  ACMENET  effort  several  aircraft  simulators  will  be  networked  together  to 
perform  both  multi-ship  training  and  training  research.  The  devices  on  the  network  will  be 
of  a  variety  of  designs  from  different  manufacturers.  They  will  also  be  of  widely  differing 
levels  of  fidelity. 


The  mission  to  be  performed  at  ACMENET  will  initially  be  several  many  vs.  many  Air-to- 
Air  scenarios.  Currently  it  is  believed  that  the  actual  number  will  be  approximately  5-6  live 
vehicles  on  each  team.  More  computer  generated  vehicles  will  also  probably  be  present. 
Although  that  is  the  vision  for  the  initial  goals;  the  eventual  goals  go  far  beyond  that 
capability.  They  encompass  the  Air-to-Air  battle  and  may  involve  hundreds  of  vehicles  or 
part  in  a  Joint  services  exercise.. 


The  principle  issues  for  networking  in  this  situation  are: 

Data  Latency  between  players 
Visual  system  differences  in  FOV,  resolution 
Electronic  emission  data  transfer 
Weapons  Fly-outs  and  Scoring  responsibilities 


All  of  these  issues  are  difficult  to  solve;  and  made  more  difficult  by  the  wide  range  of 
capabilities  required  by  the  design:  The  ability  to  support  high  fidelity  Weapon  Systems 
Trainers  interfaced  with  very  low  fidelity  part-task  trainers  in  such  a  fashion  as  to  reduce 
possible  impact  to  the  existing  devices. 


Approach  -  The  design  applied  required  the  construction  of  a  new  functional  module  to  the 
network;  called  a  Network  Interface  Unit.  The  NW  will  allow  the  existing  simulation 
hosts  to  dramatically  reduce  the  modification  required  for  network  compliance  by  handling 
most  network  specific  operations.  The  design  also  uses  the  fact  that  many  simulators  have 
been  previously  networked  using  proprietary  protocols  by  offering  several  interface 
options.  In  effect,  the  NIU  will  have  a  tailored  interface  to  the  host  and  a  very  specific 
interface  to  the  network  (SIMNET-AF). 

In  order  to  respond  to  the  electronic  emissions  that  are  vital  to  proper  Air-to-Air  training 
exercises,  the  existing  protocol.was  reviewed  for  adequacy. 
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The  existing  Radiate  PDU  was  created  to  support  experiments  with  an  AD  ATS  weapon 
systemj  a  ground-based  mobile  anti-aircraft  radar  and  gun  set.  The  existing  Radiate  PDU 
allows  intercommunication  of  the  following  parameters; 


Mode  -  Search,  Acquisition,  Track,  other 

Duty  Cycle  -  Pulsed,  Continuous 

Frequency  of  carrier 

Signal  Power 

Energy  per  pulse 

Antenna  Gain 

list  of  targets  illuminated  and  detected 


This  PDU  was  considered  for  use  in  the  ACMEnet  environment;  however  it  was  rejected  in 
its  present  form  for  a  few  reasons. 

1.  A  critical  parameter  to  many  Radar  Warning  Receivers  (RWR)  is  the  Pulse 
Repetition  Frequency  (PRF)  or  alternatively  the  Pulse  Repetition  Interval  (PRI).  This 
parameter  is  essential  to  the  simulation  of  RWRs  to  provide  correct  operation  and  response 
to  radar  emissions. 


2.  When  a  system  is  able  to  radiate  a  l^ge  volume,  the  list  of  targets  illuminated 
and  detected  could  be  enormous.  Several  training  critical  systems  have  capabilities  to  track 
more  than  the  existing  limit  of  33  targets. 


3.  Many  existing  Fire  Control  Radar  units  operate  while  changing  their 
transmission  parameters  almost  constantly  to  prevent  unwanted  interference;  the  load  to  the 
network  and/or  host  of  issuing  a  new  Radiate  PDUs  while  frequency  hopping  or  staggering 
PRFs  would  be  large.  In  addition,  the  hosts  receiving  the  data  could  be  effectively  drown 
by  volumes  of  data  regarding  other  vehicles  emissions. 

4.  Significant  modification  of  the  host  might  be  required  to  force  each  emitter  to  list 
all  vehicles  illuminated.  Typically,  only  those  targets  within  the  current  range  scale  are 
processed  for  detection  criteria,  and  in  some  modes,  only  specific  types  of  vehicles  are 
considered. 


Admittedly,  there  are  several  approaches  to  modify  the  existing  Radiate  PDU  to  resolve  the 
issues  raised.  The  ideas  expressed  here  are  the  ones  being  pursued  by  this  author. 


In  General  -  In  order  to  resolve  issues  1  3,  an  indexing  or  coding  scheme  is  suggested. 

One  of  the  drawbacks  is  that  any  player  on  the  network  must  have  prior  infomation  on  any 
other  vehicle  that  might  be  encountered.  Another  is  that  each  new  radar  unit  implemented 
would  require  modifications  to  every  players  database.  Certainly  an  expensive  penalty. 
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As  an  attempt  to  resolve  issues  2  &4,  it  is  suggested  that  the  list  of  illuminated  and  detected  _ 

vehicles  be  maintained  TO  THE  BEST  ABILI  flES  of  the  host;  I  don't  think  it  is  possible  I 

to  force  the  emitter  to  list  each  vehicle  which  will  be  illuminated.  Somehow,  though  we  * 

must  specify  that  there  is  a  priority  based  on  range  and  possibly  vehicle  type.  Additionally, 

the  host  would  include  parameters  to  describe  the  search  volume,  for  players  not  in  their  list  ■ 

which  are  concerned  about  emissions.  Uncertainty  is  a  drawback  of  this  scheme,  exclusion  | 

from  the  list  of  illuminated  targets  would  be  meaningless  for  a  player  capable  of  sensing 

radar  emissions.  ■ 

The  current  design  for  a  RadarPDU  is :  _ 

type  RadarEmission  sequence  { 

vehiclelD  VehiclelD,  I 

location  WorldCoordinates, 

system  RadarSystem.,  ■ 

mode  RadarMcde,  * 

specificData  Unsignedlnteger(64),  _ 

azimuthcenter  Angle,  ■ 

azimuthwidth  Angle, 

elevcenter  Angle,  ■ 

elevwidth  Angle, 

power  integer,  ■ 

numberlllumed  Unsignedlnteger(8), 

targetID  array  (numberlllumed)  of  VehiclelD,  h 

data  array  (num.berillumed)  of  RadarData  ■ 

}  . 

The  field  RadarSystem  contains  the  following  bit  field:  ■ 

bits  28-31  ->  RadarSystem  Category  ■ 

bits  16  -  23  ->  RadarSystem  Subcategory  ■ 

bits  0  - 15  ->  RadarSystem  ID  _ 
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RadarSystem  Categories  - 


00  - 

Reserved  (unused) 

01  - 

Air-Based  Fire  Conitol 

02  - 

Air-Based  Search 

03  - 

Ground-Based  Fire  Control 

04  - 

Ground-Based  Search 

05  - 

Sea-Based  Fire  Control 

06  - 

Sea-Based  Search 

RadarSystem  Subcategories  - 


TBD 


RadarSystem  ID  - 

00  - 

Reserved  (unused) 

01  - 

AN/APG-66  (F-16A) 

02  - 

AN/APG-68  (F-16C) 

03  - 

AN/APG-63  (F-15) 

04  - 

AN/APG-65  (F/A-18) 

05  - 

AN/APG-70  (F-15E) 

06  - 

JayBird  (MiG-21,  Su-24,  Su- 20/22) 

07  - 

(MiG-31) 

08  - 

(MiG-29) 

09  - 

(MiG-27) 

10  - 

(Su-27) 

11  - 

AN/APY-2  (E-3A) 

12  - 

SUAWACS  (IL-76  Mainstay) 

13  - 

FoxFire  (MiG-25) 

14  - 

HighLark  (MiG-23S) 
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The  field  mode  characterizes  the  current  operation  of  the  system : 

type  RadarMode  enum  (8)  { 

RadarModeSearch, 

RadarModeDopplerHPRF, 

RadarModeDopplerMPRF, 

RadarModeDopplerLPRF, 

RadarModeMonopulse, 

RadarModeAcqui  sition, 

RadarModeTracking, 

RadarModeTrackWhileScan, 

RadarModeTerrainFollo  w, 

RadarModeDataLink 

} 

The  field  specificData  is  reserved  for  future  more  complete  information  inclusion.  The 
variables  azimuthcenter,  azimuthwidth,  elevcenter,  elevwidth  all  represent  the  angles 
required  to  desribe  the  volume  covered  by  the  radar  scan.  All  angles  are  assumed  to  be  in 
vehicle  coordinates;  with  the  origin  described  by  the  location  field.  The  volume  described 
should  correlate  to  the  radar  signal  indicated  by  the  RadarMode  field. 


The  field  power  contains  the  average  power  per  solid  angle  being  transmitted  in  units  of 
dBm  (decibel  milliwatts). 


The  target  ID  field  contains  from  one  to  TBD  identifiers  of  vehicles  illuminated  by  the 
radar.  The  exact  number  of  vehicle  identifiers  present  is  specified  by  the  value  in  the 
numberillumed  field.  The  identifiers  in  the  array  are  prioritized  to  ensure  that  all  tracked 
targets  appear  prior  to  only  search  illuminations;  and  secondly  to  sort  vehicles  illuminated 
by  range. 


The  field  RadarData  contains  the  following  bit  field: 

bits  24-31  ->  RadarMode  pertaining  to  applicable  VehiclelD 
bits  0-23  ->  Specific  RadarSystem/RadarMode  data(optional) 

[Might  be  :  Polarization,  Freq  Hopping,  Staggered  PRF,  etc] 
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APPENDIX  C:  LAN/LHN  DEMONSTRATION 

At  the  1990 IITSC  BBN  assembled  a  LAN/LHN  distributed  simulation  demonstration  that 
included  participation  from  five  independant  contractors,  three  government  agencies,  and 
three  geographic  locations.  Each  participant  had  a  set  of  goals  for  the  conference 
andundertook  to  achieve  those  goals  using  a  common  network. 


Demonstrated  Capabilities 


The  system  that  was  assembled  for  IITSC  90  demonstrated  several  keyt  echnologies; 


-  Wide  Area  Networking  (Long  Haul)  of  manned  fixed  wing  aircraft  simulators. 

-  distributed  interactive  simulation  using  the  SIMNET  protocol 

-  digital  radio  simulation  and  voice  transmission 

The  three  geographic,  locations  or  sites  that  were  linked  viaterrestrial  phone  lines  to  form  the 
Long  Haul  portion  of  the  demonstration  were: 

-  Marriot  World  Center,  Orlando  FL 

-  Williams  AFB,  AZ 

-  Fort  Rucker,  AL 

The  Marriot  World  Center  in  Orlando  w^-s  the  hub  of  the  network.  The  bulk  of  the 
participants  were  located  in  booths  on  the  trade  show  floor  of  the  conference.  The  BBN 
booth  housed  a  gateway  that  enabled  digital  communication  between  the  three  sites. 


The  link  to  Williams  was  a  56KBit/sec  dial  up  line.  At  the  BBN  office  at  Williams  was  a 
single  gateway  that  received  data  from  Orlando  and  transmitted  data  to  Orlando.  The  link  to 
Fort  Rucker  was  a  T1  (1.5  MBit/sec)  line.  This  site  also  had  a  single  gateway  that 
communicated  with  the  BBN  booth  in  Orlando. 
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Ft.  Rucker  AL 
I 

156Kb 

I 

I 

Williams, AFB  Maniot  World  Center 

Phoenix,  AZ .  Orlando  FL 

T1 


Figure  1.  Geographic  network  topology. 


Devices  in  Orlando 


There  were  a  large  number  of  participants  on  the  LAN  at  IITSC  90  and  the  locations  of 
their  booths  maik  the  job  of  linking  them  in  a  trade  show  environment  difficult  but  not 
insurmountable.  The  LAN  in  Orlando  was  run,  for  convenience,  over  75  ohm  coax 
between  the  booths.  Since  the  maximum  length  specification  for  a  single  LAN  would  be 
exce^ed,  due  to  the  locations  of  the  boots,  an  ethemet  repeater  was  used  across  the  longest 
legs.  There  were  no  adverse  effects  observed  due  to  this  configuration. 


The  LAN  ran  between  five  booths  on  the  show  floor: 


-BBN 

-  General  Dynamics 

-  Air  Force  Human  Resources  Laboratory 

-  Paragon  Graphics 
-TSI 


The  hub  of  the  network  was  in  the  BBN  booth  where  the  Long  Haul  Links  were  located 
and  all  of  the  LAN  legs  terminated.  The  following  is  a  brief  description  of  the  devices 
located  in  each  of  the  booths  that  participated  in  the  distributed  exercise. 
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BBN  Devices 


On  the  network  at  the  BBN  booth  were: 


-  56Kb  Gateway 

-  T1  gateway 

-  Semi-Automated  Forces  Workstation 

-  Observation  Vehicle 

-  Digital  Voice  System 


The  gateways  were  physically  housed  in  a  single  GP-IOOO  system  but  were  logically 
seperate.  They  provided  the  digital  links  to  Williams,  AFB  AZ  over  the  56Kb  portion  and 
to  Ft  Rucker  AL  over  the  T1  portion. 


General  Dynamics  Device 


The  General  Dynamics  booth  had  an  F-16  flight  simulator  on  the  network.  Though  it 
represented  only  one  entity,  its  complexity  is  worth  presenting  here. 


The  F-16  simulation  host  consisted  of  three  Silicon  Graphics  Workstations  -  a  220  and  two 
personal  IRISs.  These  devices  computed  the  vehicle  dynamics  and  provided  the  weapons 
system  simulation  as  well  as  the  pilot/vehicle  interfaces.  Only  the  2-dimensional 
the  graphics  displays  of  the  Silicon  Graphics  Workstations  were  used.  These  provided 
overlays  of  the  out  the  window  HUD  display  as  well  as  the  head  down  multi  funcoon 
displays  (MFDs). 


The  four  out  the  window  graphics  channels  as  well  as  the  Maverick  seeker  video  was 
provided  by  two  BBN  GT-120s.  These  were  interfaced  to  the  host  over  ethemet  via  the 
BBN  provided  Network  Interface  Unit  NIU.  The  NIU  also  provided  the  host  interface  to 
the  SMNET  network  and  housed  the  Digital  Voice  System  compatible  with  that  in  the 
BBN  booth  and  at  the  remote  sites. 


The  GT-120s  served  as  the  master  clock  for  the  NIU.  They  were  run  at  15Hz  dimng  the 
demonstration,  though  during  development  they  were  run  at  30Hz.  The  Silicon  Graphics 
system  that  served  as  the  simulation  host  did  not  have  a  fixed  frame  rate  and  ran 
asynchronous  to  the  NIU  and  the  CIGs. 


The  General  Dynamics  simulator  exchanged  the  following  simulation  protocol  variants 
across  the  SIMNET  network: 

-  Vehicle  Appearance 

-  Fire 

-  Impact 

-  Deactivate 


The  term  'exchanged'  is  defined  to  mean  that  the  device  received  and  inteipreted  the  varient 
from  other  network  entities  as  well  as  sent  the  ownship  state/event  variants. 


The  General  Dynamics  simulator  transmitted  the  appearance  variants  for  itself  as  well  as  the 
air-to-air  and  air-to-ground  missiles  that  were  launched  by  the  vehicle.  The  missile 
dynamics  were  computed  by  the  Silicon  Graphics  simulation  host  as  well  as  the  tracking 
and  targeting  algorithms.  To  maintain  compatability  with  the  existing  devices  on  the 
network,  the  vehicle  type  AD  ATS  missile  was  substituted  for  the  AIM-9.  This  enabled  the 
use  of  the  existing  SAF  and  manned  simulators,  without  modifying  the  damage  tables  in 
each  device. 


The  ballistic  trajectory  for  the  30MM  gun  that  was  part  of  the  F-16  weapons  system  was 
computed  by  the  master  GT-120,  as  were  the  impact  events  generated  by  gun  employment. 


The  NIU  provided  the  host  with  several  services  related  to  the  network  Ixjyond  translating 
the  information  to  and  from  the  network.  The  NIU  provided  dead  reckoning  of  the 
appearance  of  other  vehicles.  The  list  of  other  vehicles  was  prioritized  by  vehicle  type  and 
range  and  was  clamped  to  thirty  vehicles  total.  This  clamp  was  added  in  response  to 
degraded  host  performance  as  the  other  vehicle  list  got  larger  than  30. 


Air  Force  Human  Resources  Laboratory 


AFHRL  demonstrated  the  networking  of  several  devices: 


-F-16  Combat  Engagement  Trainer  (CET) 

-  Ground  Control  Intercept  Station  (GC'U 

-  Plan  View  Display  (PVD) 

-  Data  Logj^r 


The  CET  is  a  VME  based  system  used  to  train  pilots  in  the  weapon  system  employment  of 
the  F-16.  It  was  integrated  to  the  SIMNET  network  via  an  NIU  with  Digital  Voice  System. 
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The  GCI  station  is  a  Sun  Workstation  based  device  used  to  present  the  radar  image^to  the 
GCI  controller.  This  device  was  also  interfaced  to  the  SMNET  network  using  an  NIU 
with  Digital  Voice  System. 


The  PVD  and  the  Logger  are  the  standard  BBN  developed  Concurrent  based  devices. 


Paragon  Graphics 


Paragon  Graphics  borrowed  the  Rapidly  Reconfigurable  Cockpit  (RRC)  frorn  the  Air  Force 
Human  Resources  Laboratory  and  inte^ated  it  with  their  visual  system.  The  RRC  is  a 
VME  based  system  used  to  train  pilots  in  the  employment  of  the  weapon  systems  of  the  F- 
15,  F-18,  or  F-16.  The  RRC  was  interfaced  to  the  SIMNET  network  using  an  NIU  with 
Digital  Voice  System. 


TSI 


TSI  had  two  IBM-PC  based  systems  connected  to  the  SIMNET  network.  One  device  was  a 
monitor  type  system  similar  to  the  Observation  Vehicle.  The  other  was  a  vehicle  generating 
system,  capable  of  simulating  multiple  vehicles  and  placing  them  on  the  network. 


TSI  interfaced  to  the  network  directly  and  did  not  use  an  NIU.  They  did  not  participate 
actively  in  the  exercise  and  did  not  need  a  digital  voice  link.  Unfortunatelv,  they  were 
unable  to  present  a  vehicle  on  the  network  using  the  vehicle  generator,  but  they  were  very 
sucessful  in  monitoring  the  exercise  from  their  network  monitoring  system. 


Devices  at  Ft  Rucker,  AL 


The  LAN  at  Ft  Rucker  included  the  FWA  and  RWA  simulators  introduced  earlier  in  this 
paper  These  devices,  by  nature  of  their  design,  are  fully  SIMNET  protocol  compliant.  The 
interoperation  of  these  devices  over  the  long  haul  was  transparent  to  the  devices  on  the 
LAN  in  Orlando.  The  FWA  and  the  General  Dynamics  F-16  simulator  were  able  to  oj^rate 
as  an  element  to  engage  air  and  ground  forces.  They  flew  in  combat  formation  using  visual 
reference,  communicated  over  the  digital  voice  network,  performed  rendevous  m^euvers 
directed  by  FACs,  and  perform  as  a  Joint  Aerial  Attack  Team  with  the  RWA  also  located  at 

Ft  Rucker. 


Devices  at  Williams  AFB,  AZ 


Along  with  the  gateway,  AFHRL  operated  a  GET  device,  identical  to  the  one  in  the 
AFHRL  booth,  on  a  LAN  at  Williams.  This  device  was  able  to  perform  beyond  visual 
range  intercepts  with  the  device  in  Orlando. 
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The  exercise  bandwidth  was  not  explicitly  measured.  Each  NIU  equiped  device  conformed 
to  the  first  order  DR  algorithm.  From  previous  studies  the  typical  bandwidth  required  is 
1  kbit/second  for  a  ground  vehicle  and  6kbits/second  for  an  air  vehicle.  The  voice  traffic 
consumes  20kbit/second.  On  this  basis  the  approximate  ethemet  bandwidth  consumed 
during  the  demonstration  was  less  than  ISOkbits/second  on  average.  Since  this  would 
saturate  the  56kbit  line  to  Williams,  the  exercises  were  segregated  accordingly. 
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